개요
- OS: Rocky 8.10
- 디스크 구성
/dev/sda: 메인 디스크/dev/sdb: 백업 디스크
상황
- 평소에 서버 로그에
READ sda ....,swap관련 메시지가 간간히 보였음. - 어느 날
I/O관련 로그가 많이 뜨더니 재부팅 이후 - OS가 정상 부팅되지 않고
dracut emergency shell로 떨어짐. blkid에서root UUID가 사라진 걸 홗인 -> 루트 파티션 증발- 다행히 4일 전에
/dev/sdb에 전체 rsync 백업 이 되어 있었고, 그걸 이용하여 백업 디스크로 부팅 복구에 성공하였음.
이번 글은 장애 당시 어떤 식으로 확인하고, 어떻게 백업 디스크로 부팅을 살렸는지,
그리고 아직까지도 "왜 루트 파티션만 날아갔는지"에 대한 찝찝한 부분을 정리한 기록이다.
장애 증상
재부팅 후 다음과 같은 증상이 나타났다.
- 커널/시스템 로그에서는
/dev/sda,/dev/sdb디스크 인식은 정상처럼 보임. - 하지만 부팅이 끝까지 진행되지 않고
dracut emergency shell로 진입함.
dracut 쉘에서 제일 먼저한 행동은 다음 두 가지였음.
# 현재 사용중인 커널 확인
cat /proc/cmdline
# 디스크 UUID 확인: 이 때 사용중인 커널에 lsblk, fdisk가 심어지지 않았기에 확인이 불가능했음.
blkid여기서 중요한 포인트가 있음
/proc/cmdline에는root=UUID=<루트의_UUID>가 분명히 찍혀 있었지만,blkid출력에는 해당 UUID가 존재하지 않음
루트 파티션 찾기
다음으로 /dev/sda와 /dev/sdb를 비교해봤음.
blkid/dev/sdb는 파티션 및 UUID가 전부 정상적으로 보이고 있음./dev/sda는 파티션 중 하나가 누락된 상태 (아예 보이지 않음)
이 상태에서 모든 sda 파티션에 대해 루트 구조가 나오는지 확인이 필요하였음.
mount -o ro /dev/sda1 /sysroot
umount /sysroot
mount -o ro /dev/sda2 /sysroot
umount /sysroot
...그러나 어떤 파티션에도 /etc, /var, /usr 등의 루트(/) 구조가 나오지 않음.
왜 루트만 그렇게 날라간 건지는 아직도 100% 확신은 못하지만,
운영 중에 남아있던 I/O 관련 에러 등을 참조해보면 sda 특정 영역 (루트가 올라가 있던 구간)에 물리적인 문제가 생겼을 가능성이 크다고 생각함.
어떻게 살리지?
여기서 선택지는 크게 두 가지였음.
1. sda에서 루트 파일시스템 직접 복구 시도
ddrescue라는 걸로 이미지 뜨고xfs_repair,fsck,testdisk등등 ..- 하지만 루트가 완전히 깨진 상태라 성공 보장은 없었음.
2. 이미 복제해둔 백업 디스크(sdb)를 새 메인으로 승격
- 어차피 4일 전까지의 전체 rsync 백업이 있음.
- 다운타임을 최소화하려면 이게 훨씬 효율적. (어차피 테스트 서버이기도 하고 ..)
가장 먼저 "관련 서비스"를 살려야 했기 때문에,
/dev/sdb를 부팅 가능한 디스크로 만들고, 기존 /dev/sda는 장애 디스크로 두기로 하였음.
백업 디스크로 부팅하려 했지만 ..
내 생각은 단순했다.
"백업 디스크에 전체 파일시스템 구조를 rsync로 백업해뒀으니 BIOS에서 sdb로 부팅하면 되겠지?
하지만 현실은 ...
- 부팅 메뉴에서
Legacy BIOS ..로그만 나오며 실제 OS 부팅이 안됨. - 즉, 파일은
rsync로 복제되었지만, 정작 중요한 부트로더 는 복제되지 않았음.
rsync는 파일 레벨 복사만 수행하기 때문에
MBR,GPT의 부트 코드UEFI용EFI파티션 내용GRUB부트로더 설치 정보
이런 것들은 복제되지 않는다.
결국 백업 디스크에도 GRUB을 새로 심어줘야 했다.
백업 디스크에 GRUB 심기
기존 장애난 디스크도 결국 GRUB 진입까지는 되었기 때문에,
장애 디스크로 부팅하여 GRUB 메뉴에서 rescue 모드로 진입하였다.
1. 루트 & 필수 마운트
먼저 sdb의 파티션들을 원래 역할에 맞게 마운트한다.
(아래 X, Y, Z는 실제 환경에 맞게 대체)
# 루트
mount /dev/sdbX /mnt/sysimage
# /boot 가 분리되어 있다면
mount /dev/sdbY /mnt/sysimage/boot
# /boot/efi 가 있다면 (UEFI 부팅일 경우)
mount /dev/sdbZ /mnt/sysimage/boot/efi그 다음, chroot 환경을 만들기 위해서 /dev, /sys, /proc을 바인드 마운트
mount --bind /dev /mnt/sysimage/dev
mount --bind /sys /mnt/sysimage/sys
mount --bind /proc /mnt/sysimage/proc
chroot /mnt/sysimage이 때 /dev를 바인드 마운트했기 때문에 chroot 안에서도 /dev/sda, /dev/sdb가 그대로 다 보이게 됨.
2. GRUB 설치 (Legacy BIOS 기준)
Legacy BIOS 부팅인 경우 GRUB 설치 방법
grub2-install /dev/sdb
grub2-mkconfig -o /boot/grub2/grub.cfgUEFI 환경이라면 --target=x86_64-efi, --efi-directory=/boot/efi 등으로 설치해야 한다.
3. os-prober와 /dev/sda 경고 메시지정체
grub2-mkconfig 를 실행했을 때 이런 에러가 나왔다.
/dev/mapper/control: open failed: no such device
check that device-mapper is available in the kernel.
incompatible libdevmapper 1.02.181-RHEL8 and kernel driver (unknown version)
command failed
/dev/mapper/osprober-linux-sda1: Can't open blockdev
/dev/mapper/osprober-linux-sda2: Can't open blockdev
/dev/mapper/osprober-linux-sda3: Can't open blockdev지금 분명 /dev/sdb 쪽으로 chroot해서 백업 디스크 작업 중인데,
왜 /dev/sda에 대한 os-prober 에러가 뜨지…?
사실 이유는 단순하다.
- 아까 chroot 전에
/dev를-bind마운트했기 때문에- chroot 안에서도 여전히 실제 호스트의 /dev/sda, /dev/sdb 가 그대로 보인다.
grub2-mkconfig는 내부적으로 os-prober 를 호출해서- 시스템에 존재하는 모든 OS/파티션을 스캔한다.
- 그 과정에서 이미 맛이 간
/dev/sda1~3을 건드려 보다가- “Can't open blockdev” 같은 에러를 뿜은 것.
즉, chroot가 /dev를 통째로 가져왔기 때문에,
“백업 디스크를 대상으로 작업하는 도중에도 /dev/sda를 보게 된 것” 이다.
해결 방법은 심플했다.
echo 'GRUB_DISABLE_OS_PROBER=true' >> /etc/default/grub
그리고 다시 실행:
grub2-mkconfig -o /boot/grub2/grub.cfg
os-prober를 꺼두면 sda를 억지로 스캔하려 하지 않기 때문에,
이제 불필요한 에러 없이 grub.cfg 생성이 가능하다.
4. fstab / UUID 정리 & 마무리 부팅
GRUB까지 백업 디스크에 잘 심었다면,
마지막으로 fstab과 UUID를 sdb 기준으로 맞춰주는 작업이 필요하다.
blkid # sdb 파티션들의 UUID 확인
vi /etc/fstab
/항목이 sda의 옛날 UUID 를 보고 있지 않은지- swap, /boot, /boot/efi 등이 전부 sdb 쪽 장치/UUID 를 보고 있는지
필요하면 initramfs도 다시 생성해줬다.
dracut -f
이제 chroot를 빠져나와서 재부팅:
exit
reboot
BIOS/UEFI 설정에서 부팅 순서를 /dev/sdb (혹은 해당 디스크 모델명)으로 올린 뒤,
정상적으로 Rocky Linux가 부팅되는 것을 확인했다.